1. Field of the Invention
The present invention relates to a methods of running non-native binaries on a host computer system.
2. Background Art
Currently, a large number of differing computer architectures are utilized both commercially and privately. Although many software applications exist for each of these platforms, there are frequent instances in which a desired program will not run a given architecture. This is particularly true for custom applications developed to a specialized task. Binary translation, and in particular dynamic binary translation, is utilized to provide capability of running non-native code on a host computer system.
In general, signals are events or messages that are passed between processes executing on a computer system. Signals are generated by the operating system to redirect execution in response to asynchronous activity, such as exceptions generated during program execution or user input (e.g., mouse click, ctrl+c, and the like). The occurrence of a signal causes the operating system to interrupt the normal execution of a process. Signal handlers are then deployed to deal with the signal.
FIG. 1 provides a schematic illustration of a method for running a native binary on a computer architecture that receives a signal from the operating system. Application stack 10 includes a set of instructions that are executed by the host architecture's computer architecture. A signal occurrence is illustrated by box 12. The operating system subsequently passes control to a signal handler as shown by box 14. Specifically, upon receiving a user-signal or an exception, the operating system looks up in its data structures to see if signal-handler function 16 is registered with the operating system by the application. If such a signal handler exists, the operating system builds the arguments and other data necessary to run signal handler function 16, on the application stack and starts execution at the signal handler. The arguments passed to the signal handler usually include signal information and information about the execution context. Hardware register state is part of this execution context.
FIG. 2 provides an example memory layout of the stack for each function (known as activation stacks) and the signal handler. Each computer architecture pre-defines such memory layouts and the contents of the activation stack. Generally, differing computer architectures have differing memory maps.
FIG. 3 provides a schematic illustration of two fundamental issues related to signal handling that must be addressed during dynamic binary translation. The instructions on guest application stack 20 are translated into instructions on host application stack 22. It should be appreciated that a single guest instruction may require several host instructions to be properly implemented. In this scenario, a signal occurrence is illustrated by box 24. The operating system subsequently passes control to a signal handler as shown by box 26. The first issue indicated by item number 28 relates to the setup and execution of the signal handler function as the signal handler is invoked directly by the operating system. Since the invocation is done directly by the operating system, which in our case is native to the platform, it does not understand the conventions for the guest architecture. The native operating system will pass information that can be understood by native signal handlers, but not by guest signal handlers.
The second issue indicated by item number 30 relates to getting the correct execution state (as hardware registers are emulated). The difficulty associated with establishing the correct execution state occurs due to the fact that many host instructions are needed for one guest instruction. For a native application, signals are delivered by the kernel on native instruction boundaries. For translated guest applications, signals can be delivered in the middle of guest instruction emulation. In such a situation, a guest instruction executed halfway can cause incorrect execution if execution is redirected by the signal handler to an alternate location that is dependent on the execution state being up-to-date.
Accordingly, there is a need for improved methods of executing non-native code on a host computer system.